夜天之书 #76 远程工作、开源协同与饱和沟通

上周末在给 Apache Ratis 的代码库上 Maven Wrapper 的时候，项目作者 @szetszwo 对 Pull Request (PR) 当中代码的合规问题和实现问题提出了一些问题^[1]。虽然这些问题并不难回答，但是我第一时间的反应却是“这么明显的答案，实在是懒得回复”。进而我又想到，如果是线下集中办公或者面对面 workshop 的情形，这些问题不到五分钟就能讨论清楚，而这两类不同环境当中开发者的表现差异，正好是接触和适应远程工作与开源协同的一个门槛。由此，我想讨论一下远程工作、开源协同与饱和沟通的问题。

集中办公的效率

首先声明，对于自控力和自驱力强的开发者来说，远程办公能够有效地避免心流被打断。这也让管理者无需苦恼于《人件》^[2]当中介绍的种种“办公环境”的错误实践。此外，不用耗费额外的时间通勤，以及不限居住城市的条件，对特定候选人的吸引力是决定性的。应当说，开发者群体的远程办公、分布式办公是不可逆转的趋势。支持远程办公的企业在吸引到更多高水平开发者的同时，并没有降低人效，从而市场竞争最终必然推向广泛支持远程办公。

当然，支持远程办公不意味着必须远程办公，集中办公强大的惯性和沟通效率的优势仍然支持其存在的理由。

若干年前，我在线下跟 Apache Flink 的主要作者 Stephan Ewen 交流的时候，问过他社群当中的议案，会不会因为提议者来自不同组织而被差别对待。他说这在规则上是不会的，但是实际上，同一个组织的开发者，尤其是集中办公，有问题转过头三两句就能聊清楚的团体，能够更快地调整议案达成一致，在组织对项目有一定话语权的前提下，其提议被接受和实行的概率显然是更高的。

我曾经总结过中国开发者在开源社群当中交流应该有的层次感：

例如现在有一个议案，在几个发起人初步对齐之后，先在邮件列表或论坛上发布，交流过程中发现英文词不达意的，转到微信用中文快速同步，再不行就打电话或者面见。这样，是从大范围逐步缩小到小范围，大范围同步信息，小范围解决冲突。

这里面，“初步对齐”和“面见”都是集中办公下天然就能做到的事情，能够坐到一起办公，语言往往也默认不是一个问题。然而，当一个社群逐渐吸引到不同国家不同文化背景的参与者之后，能不能 fallback 到中文沟通，能不能用微信交流，就是一个巨大的挑战。对于许多开发者来说，用英文笔谈已属不易，更不用说线上视频英文对话，甚至想办法线下面谈。

我在不少开源社群的参与当中也有这样的经历。如果我发现一个开发者是中国人，且他在 GitHub 等平台上的回应慢、理解困难，我会尝试加他的微信，中文或者电话讲清楚问题。如果同城或者日后出差经过，还能面见做深入的沟通。这样的引导可以帮助开发者逐渐成长起来，或者在目前的能力水平下做出更大的贡献。

然而，如果这个开发者是外国人，我就几乎只有 GitHub 或邮件的形式联系他，等待他的回复，而无法用他所在地的国民社交应用联系，更不可能线下见面。此外，虽然许多人下意识的把外国人都认为是说英语的人，但是 native speaker 和跟你我一样的英语第二外语的开发者，用英语沟通起来的体验也大不相同。当对方的英语跟你只是另一种与 Chinglish 不同的“方言”，你真的会发现把问题说明白都很费劲。

除了这种有沟通需要时，集中办公能够提供的效率以外，集中办公占据了个人白天的大量的时间，从而自然会导致成员之间超越工作的饱和沟通。

这种饱和沟通一方面促进了成员之间的信任和团队的归属感，从而使得相互能够理解对方行为的动机，快速领会不言而喻的意思；另一方面，在目的性不那么强的闲谈当中，往往会迸发出意想不到的创意。

Apple 的乔布斯是著名的远程工作反对者，他曾经说过“创造力源于自发的会议，来自随机的讨论。你遇到一个人，问问他在做什么，听了就说‘哇’，然后很快就有各种各样的点子冒出来。”

我在某电商公司上班的时候，CRUD 的工作每天只需要花不到两个小时的时间。剩下的时间里我会梳理团队的微服务关系和依赖的基础设施，有什么问题走到责任人桌边，往往聊两句就能知道代码背后的故事和以前到现在面临的问题。有过这样的交流，日后真的需要他人帮助时，对方对你的认识也就不局限于“这个来找我麻烦、给我增加工作量的从未谋面的人”，而是能够基于之前共同吐槽过的问题和共识，商讨当下的麻烦该怎么解决。自然，沟通过程当中只要稍加留意，你也不难发现“房间里的大象”，如果你还能把利益相关者的意见都收集起来，可能就会看到一个显而易见的解决方案。

而对于远程办公和分布式的开源协同来说，这会非常困难。因为在线闲谈的时间成本非常高昂，文字的表达能力远不及语言加上肢体动作，更不用说文字留底在工作环境下多少会为人所忌讳。而电话连线工作或者团队视频会议打开摄像头，则是一种让人无所适从的“监视”。

这样，对于一个新的团队来说，往往从未有过建立起相互了解和信任的机会；对于一个曾经集中办公的团队来说，也常常会逐渐降低交流频率，只在有求于人或者事情已经搞砸了的时候才会寻求沟通。

分布式协同的方法

虽然集中办公有必要时的沟通效率和随机讨论的创造力的优势，但是远程办公却能够维持开发者的心流，同时减少了通勤的开销和对办公地点的要求。《人件》当中对“办公环境”的讨论，旨在解决集中办公下维持开发者的心流的问题。我们可以从另一个角度出发，探讨如何在分布式协同的环境下，保持沟通的效率。

第一种方法是强化协同流程。注意，强化流程不意味着增加流程，而是在设置了必要的流程以后，明确其检查点并加以执行。

例如，比起各自为战，等到出了问题再事后补救，组织或社群都应该对关键的决策进行收拢，典型的做法是参考 RACI 模型^[3]建模。这样，责任人（Responsible）负责主导方案的制定和实施，决策人（Accountable）进行审核，领域专家（Consulted）和其他相关人员（Informed）可以提出意见，或者在责任人的协调下承担相应工作。

集中办公环境下自然也需要有职责分工，但是由于可以直接堵门，往往职责分工不明确能够被发现和提出。分布式环境下，没有通用语言^[4]会导致更加严重的分裂，其后果也更难补救。

RACI 模型的作用是在高沟通成本的环境下，确定了设置目标和制定方法的模式，从而让团队能够在共同目标和共识方法论的情况下开展工作。一旦出现问题，也能够通过讨论是否影响目标达成，以及工作方法是否需要改变来展开，避免无谓的消耗。

在这一模型下，责任人撰写议案（proposal）来设置目标和制定方法。因此，在团队或社群当中共享撰写议案的模板就尤为重要。成熟的开源社群大多有议案流程和模板，例如：

•Flink Improvement Proposal^[5]•Python Enhancement Proposal^[6]•Java Enhancement Proposal^[7]

可以看到，这些议案模板往往是以一段话简介 + 动机 + Goals/NonGoals 开头，再展开具体的设计和技术细节。我在第一次写 Flink Improvement Proposal 的时候，就因为过于关注实现，默认老板让我做的就是合理的动机，写完代码而非解决问题就是目的，而被老板带着改了三四轮议案，也从此深刻记住了动机和 Goals/NonGoals 在议案中的重要性。

Pulsar 社群最近的一个提案 PIP-256^[8] 就因为长达 46 页的第一版提案，只在最后六页含糊地写了 Goals 而被挑战。其前 40 页几乎是对相关领域的调研和基础知识的科普，更像一篇介绍性的博客而非一份需要采取行动的议案，无怪乎另一名成员两次提问到：

1.What are the exact problems we have?2.What exactly do we plan to change?

第二种方法是活动和催化。流程只能改进解决已知问题的效率，而不能激发创造性的沟通。TiDB User Group^[9] 不定期的会举报一系列的活动，邀请用户和开发者分享自己使用和开发时的案例，通过案例的交流，另一名用户可能发现解决自己问题更优的方法，另一名开发者可能发现一个没被解决好的问题可以改进。作为社群协调员，敏锐地发现这些端倪，串联起成员之间的开放式沟通，就有可能催化出创造性的成果。

《人件》有一章专门讨论“构建社区”的话题，跟这里介绍的方法就是殊途同归的。毕竟集中办公也不是每个组织团队都真的会有自发的会议和随机的讨论，只不过解决起这个问题，集中办公的环境和分布式办公的环境面临的挑战不一样罢了。

不过，上面这两种方法，也跟任何手段一样，并非喊出口号做出形式就能生效：流程不总是切实执行的，缺乏内容的活动和揠苗助长的催化只会适得其反。最终要想在分布式协同当中提升沟通效率，仍然需要依靠观念的改变：为什么我应该和他人沟通？什么时候应该和他人沟通？沟通什么？和谁？最后，才是如何高效地沟通。

参考阅读

对于分布式协同当中沟通的话题，我在《饱和沟通：开源社群的消息传递准则》当中有过一轮讨论，可以参考阅读。同样值得推荐的是《制造开源软件》对避免私下讨论^[10]的论述和第六章沟通^[11]。

References

[1] 问题: https://github.com/apache/ratis/pull/854#pullrequestreview-1347413683
[2] 《人件》: https://book.douban.com/subject/25956450/
[3] RACI 模型: https://en.wikipedia.org/wiki/Responsibility_assignment_matrix
[4] 通用语言: https://martinfowler.com/bliki/UbiquitousLanguage.html
[5] Flink Improvement Proposal: https://cwiki.apache.org/confluence/display/FLINK/Flink+Improvement+Proposals
[6] Python Enhancement Proposal: https://peps.python.org/pep-0001
[7] Java Enhancement Proposal: https://openjdk.org/jeps/1
[8] PIP-256: https://lists.apache.org/thread/2v00jx8qv1kx5b3ozgm9m242k82q7j5y
[9] TiDB User Group: https://asktug.com/
[10] 避免私下讨论: https://producingoss.com/en/producingoss.html#avoid-private-discussions
[11] 沟通: https://producingoss.com/en/producingoss.html#communications